A firewall is a gateway which operates at the same time as a connector and a separator between networks in a sense that the firewall keeps track of the traffic that passes through it from one network to another and restricts connections and packets that are defined as unwanted by the administrator of the system. Physically a firewall is a machine with appropriate software to do the tasks assigned to it. It can be a router, a personal computer (PC), a special appliance, or whatever that can be used for such purposes. A firewall is usually used for protecting an internal network of an organisation and for connecting the internal network to a public network, such as Internet. On data packet level a firewall filters data packets, which are entering and/or exiting the internal network. The rules according to which the data packets are filtered are defined in access rules. In addition to filtering data packets a firewall may secure data packets transmitted between, for example, some communication entities. In this case the firewall operates both as a firewall and a security gateway, such as a VPN (Virtual Private Network) gateway.
FIG. 1 illustrates an example with a first internal network 12, a second internal network 14 and a public network 10. The public network may be, for example, the Internet. The internal networks 12, 14 are connected to the public network 10 via firewalls 16 and 18, respectively. The firewall 16, 18 may be implemented as a single network node (server) or as a cluster of nodes. In FIG. 1, the firewall 18 is a firewall cluster comprising nodes 19a, 19b and 19c. The term security network element is used in this description for referring to a security network node or to a cluster of security network nodes, such as firewalls or routers, where data packet filtering is performed and which connects at least two networks to each other. A security network element may be, for example, a plain firewall node filtering packets or a firewall node provided with VPN functionality, or a cluster of such nodes.
Frequently, the access rules of a firewall are expressed as a table or list (rule base) of rules comprising data packet characteristics and related actions. The rule base is a central part of a security policy of a firewall. The data packet characteristics in rules are parameter values that are obtained from header fields of a data packet and may be e.g. source IP (Internet Protocol) address, destination IP address and service (or protocol) or some other values. The action gives information about how to handle a data packet, which corresponds the data packet characteristics defined in the respective rule (i.e. which matches the rule). This means that for a data packet, which has the header information indicated in a rule, the action indicated in the rule is carried out. In a firewall, the action is typically discard or allow (or deny/accept), which means the data packet is discarded or allowed to proceed, correspondingly. The rules of a rule base are examined in certain order until a decision how to process the data packet is reached. The order of the rules in the rule base typically defines the order in which header fields of a data packet are compared to the rules, that is, the rules are examined one by one from the beginning of the rule base. When a rule, to which the characteristics of a data packet match, is found, the action that is related to that rule is taken and often there is no need to continue examining the rules. However, the action defined in the rule may be continue, in which case examining the rule base is continued from the next rule, or jump, in which case examining the rule base is continued from the rule specified in the jump action. The action of the firewall may be as well refuse, which is similar to discard action. The difference is that discard action results in simply discarding the data packet and in refuse the sender of the data packet is notified of discarding the data packet.
In order to ensure that the firewall operates in desired way the firewall must be configured and managed accurately by a professional administrator. The firewall's management interface typically allows the security administrator to define various different kinds of rules. For example rules may be defined for individual hosts, host-groups, networks or IP (Internet Protocol) address ranges. In addition, the order of the rules in the rule base affects the operation of the firewall. That is, if there are two or more rules to which an individual data packet would match, the one that comes first in the rule base is taken into account. For this reason, the rules of a rule base need to be inspected as a whole when the operation of a firewall is analysed. However, the size of the rule base may be very large especially if the network that is protected with the firewall is large (and heterogeneous with regard to protection requirements). Also the structure of the rule base may be complex and the real effects of rules may not always be clear. Therefore, management of a firewall is a complex administrative task, in which mistakes are easily made.
Furthermore, the rule base used in a firewall is updated every now and then due to changed security requirements. Even a small change in the rule base may have a large effect on the total outcome and therefore also updating needs to be done by a professional administrator. In companies with several firewalls and sites, there is a need to share the responsibility and workload of managing and configuring the firewalls. However, not all administrators can necessarily be given the same rights in managing the firewalls. There may be need to enforce some general rules in firewalls organization wide and to set limitations to local administration without unnecessarily limiting the local administrators ability to make allowable changes.
Rule base templates are one possible way to control the structure of the rule base and to set non-editable rules to rule bases. For example only a super user (a special administrator whose management rights are not restricted in any way) can edit the templates, whereupon a normal administrator can edit only rule bases and a rule base is constructed on top of a template, which consists of rules like a normal rule base. Additionally the template may comprise special insert points, which are the points where the normal administrator can edit the rule base. A simple exemplary template is shown in the following:
Rule #SourceDestinationServiceAction1BCHTTPAllow2INSERTPOINT3ANYANYANYDiscard
The exemplary template above means that the first and the last rule in the rule base are fixed rules #1 and #3. A normal administrator would be able to add rules in the insert point after rule #1, but he/she cannot edit the rules #1 and #3, whereupon a rule base that extends from the template above, could look like the following for example:
Rule #SourceDestinationServiceAction1BCHTTPAllow2.1ACHTTPAllow2.2ADANYAllow3ANYANYANYDiscard
In this example the normal administrator has added rules #2.1 and #2.2, whereupon the HTTP (HyperText Transfer Protocol) data packets from source A to destination C are allowed and any data packets from source A to destination D are allowed to proceed. But the normal administrator cannot for example deny HTTP traffic from B to C, which is allowed in rule #1. In this way the super user can restrict the management rights of a normal administrator by defining suitable template rule bases. The disadvantage of using templates is that, defining suitable, restrictive enough, but not too restrictive, templates may be very difficult.
ACLs (access control lists) are another theoretical possibility for restricting management rights of normal administrators. An ACL could be defined for each rule, but since the order of the rules plays a central role in the total effect of a rule base, this may not even possible.
Security policy may contain also NAT (network address translation) rules. NAT is the translation of an Internet Protocol address (IP address) used within one network to a different IP address known within another network. Typically, a company maps its internal network addresses to one or more public IP addresses and unmaps the public IP addresses on incoming packets back into internal IP addresses. NAT also conserves on the number of public IP addresses that a company needs and it lets the company use a single (or a limited number of) IP address for connecting a plurality of computers to public networks. NAT rules are often processed in a firewall after a matching access rule, which allows the data packet, is found. Naturally, if the data packet is not allowed, no NAT rules are required to be processed. The matching system of the NAT rules is similar to access rules, but the action of the NAT rules is to change the source and/or destination addresses of the data packets to be processed.
In access rules the source and destination addresses are always expressed as addresses that are in the header of the data packet to be processed. If a destination NAT is defined for the data packet (network address translation for the destination address), the destination address in the data packet header is not the real address of the destination. Since the destination addresses are not always the true addresses there is a risk to get confused about the effects of a rule when defining a rule base. There is an example of a destination NAT rule below. The rule is applied if the source and destination addresses in the header of the data packet to be processed on HTTP service match to the NAT rule, whereupon the original destination address C of the data packet to be processed will be translated to E according to the NAT rule.
Rule #SourceDestinationServiceNAT1BCHTTPDestination NAT C → E
If source NAT (network address translation for the source address) is defined for a data packet the source address of the data packet is changed. Source address is always the true source address in the access rules, so this doesn't cause similar confusion as the destination NAT. The use of NAT rules makes analysing the total effect of rule bases even more difficult.
In addition, NAT rules make it possible to accidentally or purposefully override the effect of fixed template rules. For example the following rule base with template rules #1 and #3 and rules #2.1 and #2.2 of a normal user can be considered:
Rule #SourceDestinationServiceAction1BEHTTPDiscard2.1BCHTTPAllow2.2ADANYAllow3ANYANYANYDiscard
The normal administrator may add for example a destination NAT rule, where the destination address is changed for the data packets to be processed like:
Rule #SourceDestinationServiceNAT1BCHTTPDestination NAT C → E
Now, if an HTTP data packet from B destined to C is processed, it is first compared to rule #1 of the rule base, which does not match because of the destination. Therefore, it is compared next to rule #2.1 of the rule base, which is a match, because the source and destination and service match. According to this rule (rule #2.1 of the rule base) the packet is allowed to proceed. Then, the associated NAT rule is applied to the data packet, which changes the destination address of the data packet to E. So HTTP data packet from B to E is allowed in this way, which is clearly in conflict with the template rule #1 of the rule base. Therefore, using templates alone do not give guaranteed result of total effect of the rules.
Therefore, there is a need for a method to enforce and/or verify the total effect of rules in a rule base.